feat(org-spec-audit): one question, one issue — the ledger becomes the artifact - #142

…e artifact

The sweep filed a dated `<date>.md` in a draft PR every morning. Two sweeps
two days apart asked three of the same questions twice — two of them under a
byte-identical `maintenance-key` (org#147, org#148).

An identical key that re-proposes rules out the obvious cause and leaves the
real one: **the ledger could only remember "no", never "asked".** Both
suppression rules key off a TERMINATED proposal — declined in the ledger, or a
PR closed unmerged — and the first PR was neither. It was open, unanswered, in
the queue, which the design read as no signal at all. The unstable key was the
second cause and would have fixed one duplicate of the three.

So the unit is the question and the artifact is a GitHub issue. open = asked
(write nothing), closed = decided (never re-file, never reopen), absent = new.

- `createIssue` on the github-app surface, `openIssue` on `GithubService`. It
  FAILS rather than degrading to a logged no-op, unlike `openDraftPullRequest`:
  a PR write that no-ops leaves its content in git and its branch idempotent,
  while a no-op here drops the only copy of the question.
- `listIssues` gains `strict`, which throws instead of returning a list the
  page ceiling cut short. A dedup read cannot use a partial list — it answers
  "not filed" for everything it never reached — and a bare array cannot
  distinguish "ended on a short page" from "ended on the ceiling".
- `IssueRef.closedAt` — the column `pulls` lacks and `issues` has.
- Reconciliation: exact key match first, then ONE model call over the residue
  asking "one of these, or new?". Every answer is checked against the keys
  actually read from the control repo, so a hallucinated match files the
  question rather than silently burying it. The prompt now asks for noun-phrase
  keys (`pipeline-dags`, not `adopt-pipeline-dags`).
- The dedup read happens BEFORE the sweep and fails CLOSED, inverting the
  suppression primitive's posture: an unreadable ledger cost one duplicate PR,
  an unreadable issue set costs a duplicate of every question at once. The
  declines ledger still fails open — its failure costs one issue a human
  closes, and that close then suppresses it for good.
- `checkSuppression`'s `headBranchPrefix` is optional; omitted, the PR-history
  read is skipped entirely rather than made and ignored.
- The notice is a delta: filed today with links, standing open count, what the
  per-sweep cap held. `max-new-questions` bounds the writes; the old per-group
  rendering cap is gone.
- The github fake appends every `openIssue` to the list `issues` reads back, so
  "the second sweep sees the first sweep's issue" is testable at all.

Config: `questions-dir` retires for `questions-label`, `lane-label-prefix` and
`max-new-questions`. A label that is set-and-unusable fails the run instead of
falling back — it is both the filter the read applies and the label the write
applies, and a comma makes those two different things silently.

Design: fractalboxdev/org#150.

…e needs its url

Two findings from pr-review, both real.

`strict` inherited the library's 5-page default, so once the control repo held
500 label-filtered issues EVERY sweep would fail — permanently, five API calls
in. The ledger read now asks for 20 pages, and the error names the remedy. Read
the number as a canary: 2,000 questions asked and never closed is not a
pagination problem, it is the loop having outrun the team, and a red run there
beats one deciding on the first 500. It costs nothing until then — pagination
stops on the first short page.

`IssueCreated.url` was documented as never-empty and wasn't. A caller announces
the issue by linking it, so `createIssue` now fails on a missing `html_url` the
same way it fails on a missing number, rather than publishing a link to nowhere.

The fake records `maxPages` and the run test asserts the raised ceiling, so a
later edit dropping it cannot silently restore the five-page failure.